<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE topic
  PUBLIC "-//OASIS//DTD DITA Composite//EN" "ditabase.dtd">
<topic id="topic1"><title id="ej20941">SET ROLE</title><body><p id="sql_command_desc">Sets the current role identifier of the current session.</p><section id="section2"><title>Synopsis</title><codeblock id="sql_command_synopsis">SET [SESSION | LOCAL] ROLE <varname>rolename</varname>

SET [SESSION | LOCAL] ROLE NONE

RESET ROLE</codeblock></section><section id="section3"><title>Description</title><p>This command sets the current role identifier of the current SQL-session
context to be <varname>rolename</varname>. The role name may be written as either
an identifier or a string literal. After <codeph>SET ROLE</codeph>, permissions
checking for SQL commands is carried out as though the named role were
the one that had logged in originally.</p><p>The specified <varname>rolename</varname> must be a role that the current session
user is a member of. If the session user is a superuser, any role can
be selected.</p><p>The <codeph>NONE</codeph> and <codeph>RESET</codeph> forms reset the
current role identifier to be the current session role identifier. These
forms may be run by any user.</p></section><section id="section4"><title>Parameters</title><parml><plentry><pt>SESSION</pt><pd>Specifies that the command takes effect for the current session.
This is the default.</pd></plentry><plentry><pt>LOCAL</pt><pd>Specifies that the command takes effect for only the current transaction.
After <codeph>COMMIT</codeph> or <codeph>ROLLBACK</codeph>, the session-level
setting takes effect again. Note that <codeph>SET LOCAL</codeph> will
appear to have no effect if it is run outside of a transaction.</pd></plentry><plentry><pt><varname>rolename</varname></pt><pd>The name of a role to use for permissions checking in this session.</pd></plentry><plentry><pt>NONE</pt><pt>RESET</pt><pd>Reset the current role identifier to be the current session role
identifier (that of the role used to log in). </pd></plentry></parml></section><section id="section5"><title>Notes</title><p>Using this command, it is possible to either add privileges or restrict
privileges. If the session user role has the <codeph>INHERITS</codeph>
attribute, then it automatically has all the privileges of every role
that it could <codeph>SET ROLE</codeph> to; in this case <codeph>SET
ROLE</codeph> effectively drops all the privileges assigned directly
to the session user and to the other roles it is a member of, leaving
only the privileges available to the named role. On the other hand, if
the session user role has the <codeph>NOINHERITS</codeph> attribute,
<codeph>SET ROLE</codeph> drops the privileges assigned directly to the
session user and instead acquires the privileges available to the named
role. </p><p>In particular, when a superuser chooses to <codeph>SET ROLE</codeph> to a non-superuser role,
    they lose their superuser privileges.</p><p><codeph>SET ROLE</codeph> has effects comparable to <codeph>SET SESSION
AUTHORIZATION</codeph>, but the privilege checks involved are quite different.
Also, <codeph>SET SESSION AUTHORIZATION</codeph> determines which roles
are allowable for later <codeph>SET ROLE</codeph> commands, whereas changing
roles with <codeph>SET ROLE</codeph> does not change the set of roles
allowed to a later <codeph>SET ROLE</codeph>.</p>
<p><codeph>SET ROLE</codeph> does not process session variables specified by the role's
<codeph>ALTER ROLE</codeph> settings; the session variables are only processed during login.</p></section><section id="section6"><title>Examples</title><codeblock>SELECT SESSION_USER, CURRENT_USER;
 session_user | current_user 
--------------+--------------
 peter        | peter

SET ROLE 'paul';

SELECT SESSION_USER, CURRENT_USER;
 session_user | current_user 
--------------+--------------
 peter        | paul</codeblock></section><section id="section7"><title>Compatibility</title><p>Greenplum Database allows identifier syntax (<varname>rolename</varname>), while
the SQL standard requires the role name to be written as a string literal.
SQL does not allow this command during a transaction; Greenplum Database
does not make this restriction. The <codeph>SESSION</codeph> and <codeph>LOCAL</codeph>
modifiers are a Greenplum Database extension, as is the <codeph>RESET</codeph>
syntax.</p></section><section id="section8"><title>See Also</title><p><codeph><xref href="./SET_SESSION_AUTHORIZATION.xml#topic1" type="topic" format="dita"
    /></codeph></p></section></body></topic>
